Esittely latautuu. Ole hyvä ja odota

Esittely latautuu. Ole hyvä ja odota

Tik Ohjelmistoprojektien Hallinta

Samankaltaiset esitykset


Esitys aiheesta: "Tik Ohjelmistoprojektien Hallinta"— Esityksen transkriptio:

1 Tik-76.612 Ohjelmistoprojektien Hallinta
Luento 8 – Projektien erilaisuudet

2 Luentokartta synty suunnittelu käynnistys ohjaus päätös operointi
Kurssin aloitus To 14.3 Projektin synty Ti 19.3 Projektisuunnitelma To 21.3 Projektin käynnistäminen Ti 26.3 Työmäärien arviointi To 4.4 Projektin ohjaus Ti 9.4 Projektihallinnan työkalut To 11.4 Projektien erilaisuudet Ti 16.4 Laadunohjaus ja leadership Ti 18.4 Projektin päättäminen To 23.4 Ohjelmistotuoteliiketoiminta

3 Määritelty kesto, eri vaiheita
Projekti Määritelty kesto, eri vaiheita Määritelty aloituspiste Määritelty lopetuspiste Tarve Resurssitarve Tarve tyydytetty Projekti Tuki ja / tai linja-organisaatio Yrityksen tukiorganisaatio tukee projektia (ja muita projekteja) peruspalveluilla projektit ovat aina erilaisia. malli auttaa arvioimaan tarvittavan työn, mutta koska tavoite ei ole sama (koska liiketoiminta, ympäristö, yms. on erilainen), niin myös projekti on aina uniikki. synty suunnittelu käynnistys tekeminen päätös operointi ohjaus

4 Luennon tavoite Projektien erilaisuudet -osuuden tarkoituksena on antaa opiskelijalle hyvä kuva siitä, millaisia eri tyyppisiä ohjelmistoprojekteja on, mitkä ovat niiden tunnuspiirteet ja rakenne, sekä mitä erityispiirteitä kunkin hallintaan liittyy.

5 Projektin lähestymistapa
+ Metodologia + Elinkaari + Osaamisalueet + Projektin tyyppi (räätälöity/paketti/komponentti) = Projektin lähestymistapa

6 Miksi Metodologia? Projekti A Projektinhallinta ja kehitysprosessi kunnossa Projekti B Teknisesti pätevää porukkaa Onnistuu suuremmalla todennäköisyydellä Epäonnistuu suuremmalla todennäköisyydellä + Siirtää osaamista ihmisiltä organisaatioon ”best practice” + Tärkeä tekijä projekteja myydessä + ”One Company”

7 Metodologia -> Projekti
Metodologia määrä projektille Läpivientitavan = elinkaarimallin (= prosessin) Tehtävät Lopputulokset (dokumentit, jne) Lisäksi metodologiassa tulisi olla Apuvälineitä (how-to) Roolikuvauksia Estimoinnin apuvälineitä

8 Metodologia? Kyllä Ei RUP (Rational Unified Process)
XP (Extreme Programming) BIM (Business Integration Methodology, Accenture) .. Ei CMM (Capability Maturity Model) ISO 9001 (Laatumalli) SPICE ...

9 Accenture Business Integration Methodology and Delivering Phase Approaches

10 The Business Integration Methodology
Managing Operating Delivering Planning Purpose of slide: To further define the BI Methodology, introduce the graphic representation of the Methodology, the chevron, as well as the four phases in relation to their location on the chevron. Script: The Business Integration Methodology is a thorough approach to driving and sustaining change in an organization to create value. It encompasses the full lifecycle of a change effort and is organized into four “phases” that reflect the natural flow of work -- from an initial concept to the ongoing operation of a business capability. We’ll go into the four phases in detail in a few minutes. But it is important to mention that the BI Methodology is supported by tools, such as BI Designer, that decrease the complexity of managing engagement data and deliverables, and training that helps our workforce apply the BI Methodology. The Business Integration Methodology chevron depicts the way in which changes are planned, delivered, and introduced into the ongoing management and operation of a business. The BI Methodology is applied with experience to address the unique needs of each client. It is intended to provide a flexible approach to support the business issues and needs of each unique client situation. The basic framework of the BI Methodology should be used, and the specific components selected and adapted to meet those unique needs. (The following paragraph leads into the next slide, which discusses the Business Capability and Journey Management.) The Business Integration Methodology helps create value by focusing on business capabilities and the journey management required to develop, deliver, and sustain those capabilities.

11 BIM kerrosta syvemmältä

12 “Formulates plans to capitalize on opportunities”
Planning Phase “Formulates plans to capitalize on opportunities” Business Diagnosis Provides internal and external context for change. Strategic Direction Describes the organization’s vision. Operating Strategy Defines approaches to execute the strategy. Purpose of Slide: To Define the structure of the Planning phase. Script: Business Diagnosis Provides Internal and External Context for Change Planning begins by developing an initial understanding of the organization’s competitive environment, its strengths and weaknesses, and opportunities for improvement. A Business Diagnosis adds value by providing 1) an objective initial assessment of an organization’s health; 2) valuable insight into the way an organization works; 3) confirmation that the organization’s initial goals and expectations are reasonable; 4) recommendations that will steer the organization toward opportunities to enhance competitive advantage and stakeholder value; and, 5) guidance to determine which stage of work should be next: Strategic Direction, Operating Strategy, or Business Architecture. Strategic Direction Describes the Organization’s Vision This stage describes the organization’s visions: what business it will be in, what products and services it will deliver, what broad goals it will seek to achieve, and what value it will deliver to customers, employees and shareholders. Activities include: 1) conducting a rigorous analysis of the company’s competitive environment; 2) applying “issue-based problems solving” to determine the best approach to address organizational challenges; and, 3) developing strategies which the organization can execute with excellence to achieve a sustainable competitive advantage. Operating Strategy Defines Approaches to Execute the Strategy Operating Strategy looks at a wide range of options and then examines and eliminates possible alternatives until the best one is selected. Formulating an Operating Strategy: 1) requires a framework for thinking out of the box; 2) involves, where appropriate, looking outside the organization for ways to work with other companies to compensate for weaknesses and build on core strengths; and, 3) generates, evaluates, and selects operating options in a clear and systematic way. Business Architecture Creates a Blueprint and Defines the Business Capabilities This stage further defines what the new business capabilities will look like. It is the point at which Business Integration is designed into plans. It sets the stage for the Delivering work that will follow Business Architecture by: 1) creating the conceptual design of the operating model; 2) providing a practical and integrated implementation plan; spelling out how the new business capabilities will be phased into the organization; 3) establishing performance targets for each capability; 4) identifying the milestones at which specified levels of value and benefits will be achieved; and, 5) providing management with a powerful communication vehicle for building commitment to the change. Business Architecture Defines the business capabilities. Creates a blueprint for achieving the strategy

13 “Puts plans into action”
Delivering Phase “Puts plans into action” Capability Analysis Defines the scope, targets, and release plan for the capability. Capability Release Design Puts the Business Capability Blueprint into effect. Purpose of Slide: To define the structure of the Delivering phase. Script: Capability Analysis Defines the scope, targets, and release plan for the capability. This stage defines the requirements, implementation constraints, and delivery options for the capability. This information will help determine how the capability should be created. Capability Analysis: 1) defines the scope of the capability, articulated as a set of requirements and constraints; 2) refines the business performance model, including the set of capability measurements and targets that will govern subsequent Delivering and Operating activities; 3) creates a release plan that defines the increments by which the capability will be built and deployed; 4) articulates a deployment strategy that identifies the different deployment units; and, 5) prepares quick wins for implementation. Capability Release Design puts the Business Capability Blueprint into effect This stage defines how the elements of business process, human performance, and technology will combine to meet the business performance model by: 1) implementing quick wins to generate initial benefits, build deployment experience and create momentum for the program; 2) completing the release design, identifying all elements required for Capability Release Build and Test; 3) fully defining the business process models; 4) validating the capability release design against the business performance model; and 5) ensuring that teams have considered all elements of the BI Blueprint in their designs. Capability Release Build and Test Produces and Pilots the New Capability This stage builds, assembles, and tests all elements underlying the process, human performance, and technology changes. Capability Release Build and Test: 1) completes the detailed design, build, and test of the full scope of the release; 2) tests the capability at the individual component, assembly, product, and release levels; 3) validates that the capability fits within the overall infrastructure and integrates with other capabilities; and 4) demonstrates operational readiness through experience obtained in deploying and operating a pilot site. Deployment Puts the New Capability into Action The Deployment stage introduces the new capability into the targeted operating units. It: 1) tailors the capability according to local operational and market conditions; 2) activates the business capability; 3) stabilizes the operations of the capability before passing management responsibility to line personnel; and, 4) activates the appropriate management metrics, service level agreements, and operating level agreements to implement and realize the business performance model. Capability Release Build and Test Produces and pilots the new capability. Deployment Puts the new capability into action.

14 “Focuses on ongoing operations and improvement”
Operating Phase “Focuses on ongoing operations and improvement” Service Operations Operates new business capabilities to achieve the desired result. Purpose of Slide: To further define the Operating phase. Script: While the Service Operations stage focuses on operating the business capability itself, the Application Management discipline is concerned with the management of the underlying application. The principles that differentiate the Operating phase from the other phases are that: This phase represents the operation of the business capability that was developed and deployed during the Delivering phase, including business processes, human performance, and technology; The focus for all activities is long-term---several years, instead of weeks or months; Continuous improvement is used to sustain value. The team's standards are raised periodically in order to improve results. This process can achieve a reduction in cost and an increase in value. The success of the Operating phase depends on consistent and improved business outcomes. Operating is the point in the Methodology at which the vision for the new capability comes to life -- where the change effort’s benefits are realized and sustained over time. The deliverables and techniques included in the Operating phase help provide greater oversight and facilitate continuous improvements to the operations in order to achieve value. Application Management Extends and improves application software performance.

15 “Provides oversight, guidance, and rigor”
Managing Phase “Provides oversight, guidance, and rigor” Purpose of Slide: To further define the Managing phase. Script: Project Management Discipline Project Management focuses on providing specific deliverables (for example, process flows, job designs, business applications, reward systems) through the balanced management of scope, quality, effort, risk, and schedule. Project Management applies to the efforts coordinated by the programs, and also to stand-alone projects that may be performed before the necessary program infrastructures have been established. Program Management Program Management focuses on the continuous guidance needed to support the delivery of a business capability through multiple projects and releases. Appropriate disciplines, techniques, and tools are used to plan and organize the work and to manage the incremental delivery of the new business capability. Journey Management A complex change journey may involve multiple programs carried out over a number of years. The Journey Management discipline focuses on achieving the overall business goals by setting and adjusting an appropriate course of action to reflect business context. External context factors, such as competitor activity or the regulatory environment, are monitored so that management can keep programs relevant to the marketplace. Internal context factors, such as employee commitment to change and continued relevance of the business case, are assessed and mitigating actions are taken to address potential risks. Formal measurement techniques are used to provide feedback on a broad set of progress indicators throughout the change journey, including the realization of benefits as defined in the Business Case.

16 Hierarkisesti kuvatut prosessit
BIM:n Rakenne Hierarkisesti kuvatut prosessit Phase (Plan, Deliver, Operate, Manage) Stage/Discipline Major Activity (Delivering and Managing phases only) Task Package Task Lopputuotokset Apuvälineet Roolit ja organisaatio Konseptit Estimointi

17 BIM konseptit

18 Testaus ja BIM

19 Seven Key Principles Drive the BI Methodology
Always do a business diagnosis Focus on value: build on a business case Define implementable strategies and solutions Focus on delivering a business architecture Create business capability Commit to work in stages Use journey management to build leadership, sponsorship and ownership Slide to be used at the discretion of the presenter. The dual focus on Business Capabilities and Journey Management is reflected in the seven key principles of Business Integration. Always do a business diagnosis. Business Diagnosis is the “filter” that evaluates an organization’s goals and expectations. It reveals an organization’s strengths, weaknesses, and competitive situation and gives context for change journey decisions Focus on value: build on a business case. Focusing on value requires defining and managing the change journey based on business need and business results. The business case builds out the value proposition and becomes a living document to be managed and updated throughout the change journey. It is created in the Planning phase, provides a foundation for activities in the Delivering phase, and is the basis for measurements used in the Operating phase. Define implementable strategies and solutions. An organization realizes the value of its strategy only when the right capabilities are in operation and performance is significantly improved. This, in turn, requires a balance between the visionary and pragmatic aspects of strategy. It requires integrating an organization’s strategy with its operations. This integration is critical fur sustained business performance and competitive advantage. Create a Business Architecture. The business architecture describes the scope of change : what direct the business is heading, the changes it will make to get there, and the performance measures it will use to track the value gained. A Business Integration Blueprint captures the elements of Business Integration -- people, process, technology -- and their interrelationships. The Blueprint is the organizing framework for defining the scope of the business integration solution. Focus on delivering a business capability. A business capability is a complete entity. Making business capabilities the focus of work encourages teams to think through all of the dimensions of a solution. Commit to work in stages. Segmenting a change journey helps to keep the change and associated risks under manageable control. Stages of work are based on important decision point and major deliverables. This facilitates informed decision making and confirms that sponsor requirements are sufficient for moving forward. Use Journey Management to build leadership, sponsorship, and ownership. A successful change journey requires organization-wide leadership, sponsorship, and ownership for the change process. This is accomplished through communication and related activities that create a “pull” for the change start the “cascade” of leadership, sponsorship, and ownership.

20 (Accenturen) menetelmissä tunnistetut projektien tyypit
Kaupalliset tai konsulttitalojen menetelmistöt esittelevät projektin läpiviennin vaiheistuksen: räätälöidyt ratkaisut (tehdään itse) pakettien käyttöönotto komponettikehitys

21 ”Tehdään itse” suunnittelu ja toteutus
Saadaan varmasti sitä mitä halutaan Hinnan ja aikajänteen takia ei kovinkaan suosittua tänä päivänä

22 Pakettiohjelmiston käyttöönotto
Paketin mahdollisuudet vs. business vaatimukset Hintavertailuja Testaaminen usein vaikeata, koska paketin sisään ei nähdä A majority of the functionality and architecture elements are given as part of the packaged software documentation. Organizations choose packaged software solutions as a way to minimize development time and costs. However, this then imposes the constraints of the selected packaged software on the organization. The organization needs to be willing to change the way they do business if the packaged software does not support it or be willing to accept the risks of building customizations outside of the application. A packaged software solution is not simply a technical solution. It must involve the integration of all elements within the Business Capability Blueprint if it is to be successful.

23 Komponettipohjainen suunnittelu ja toteutus
Nopeasti valmista Sopii tilanteisiin joissa odotukset ovat epäselvät ja muuttuvat jatkuvasti Arkkitehtuurien merkitys kasvaa Design vaikea kommunikoida ilman erillistä demoa/protoa Vaarana liiat luulot nopeasti valmiiksi saadun kaikkivoipaisuudesta Ask yourself: Do you see this as an organizational and project management nightmare from beginning to end? Are you worried about the labyrinth that awaits you once you dive into the more technical aspects? Are you skeptical of whether you are actually able to deliver a good lasting product under such conditions? A well-managed component approach can help deal with these issues, if properly applied. Although eCommerce presents a new set of challenges and rewrites of many parts of the rulebook, there are proven approaches from more traditional projects that you can still apply. In particular, the component development approach provides flexibility, adaptability, maintainability, reusability, and scalability, among other things. This approach may be an excellent choice to deliver your next eCommerce solution. What are Components? Throughout the industry the word "component" is used broadly and often loosely. Components may mean very concrete things such as JavaBeans, ActiveX controls, and COM objects. They may also refer to more generic entities such as applications, architectures, designs, Web interfaces, servers, and business concepts. In the Component Development Route and Object Development Extension of the BI Methodology, we broadly classify components into the following three types: Business Components A means for modeling real-world concepts in the business domain. Examples include: Customer, Product, Order, Inventory, Pricing, Credit Check, Billing, and Fraud Analysis. You might think of a Business Component as a depiction or portrait of a particular business concept. As a whole, a business component model is a depiction or portrait of the entire business. Partitioned Business Components Independent pieces of software, or application building blocks that implement real-world business concepts. Note that the mapping from Business Components to Partitioned Business Components is not one-to-one. For example, an Order Business Component may be implemented by two Partitioned Business Components: a VB front-end Order Entry component and a CORBA back-end Order Processing component. Engineering Components Independent pieces of software to provide functionality that are generally useful across a wide range of applications. Examples include: A workflow engine A JavaBean that encapsulates a reusable concept such as an address or monetary unit A complex widget that allows users to edit a list of order lines A group of objects responsible for persistence  A JavaBean that sorts a collection of objects A simple list box coded as an ActiveX control

24 Projektinhallinnan malleja
Menetelmistöt hyödyntävät eri lähestymistapoja ohjelmistokehitykseen vesiputous (kalaportaat) iteratiivinen kehitys

25 Vesiputousmalli ja kalaportaat
Vaatimusten määrittely Määrittelyn tarkennus Järjestelmä- ja sovellussuunnittelu Toteutus ja yksikkötestaus Integraatio- ja järjestelmätestaus Hyväksymis- testaus Käyttöönotto ja ylläpito

26 Iteratiivinen kehitys
% valmis 1. Iteraatio 2. Iteraatio 3. Iteraatio Analyysi Suunnittelu Toteutus ja testaus 1. järjestelmäversio Iteratiivinen kehitysmalli käsittelee kehitystyön riskejä seuraavilla tavoilla: Hankkii varhaisempaa palautetta sponsoroivalta organisaatiolta Tutkii riskialttiit alueet (toiminnalliset tai tekniset) ja testaa ne varhaisessa vaiheessa Identifioi vielä tuntemattomia ongelmakohtia Sopeutuu joustavammin Antaa varhaisempaa ‘hands-on’-tuntumaa kehitystiimille

27 Järjestelmäversiot 1. versio 2. versio 3. versio Kk Järjestelmän jatkoversiot (incremental releases) ovat osa laajempaa kyvykkyyttä (business capability). Niillä tulisi olla seuraavat ominaisuudet: Tuottaa välitöntä lisäarvoa sponsoroivalle organisaatiolle (ja sen asiakkaille). Tukee tiettyä rajattua tavoitekokonaisuutta, joka on osa täyden toiminnallisuuden tavoitteista Toimitettavissa verrattain lyhyessä ajassa Otetaan käyttöön loppukäyttäjille/asiakkaille Riittävän joustava jotta uutta toiminnallisuutta voidaan lisätä myöhemmissä versioissa Helpottaa nykyisten käyttäjien siirtymistä myöhempiin versioihin

28 Projektinhallinnan tekniikoita
Menetelmissä käytetään tiettyjä tekniikoita riippumatta lähestymistavasta protoilu timeboxing testauksen v-malli

29 Protoilu Fidelity, täsmällisyys Interaction, käytettävyysw

30 Figure 1.0 Conceptual View of a Timebox
Timeboxing Määritelmän mukaisesti kukin neljästä osatekijästä on kiinnitetty. Jokin neljästä, useimmin aikataulu sanelee. Resurssit Lopputuote Tehtävät What Is Timeboxing? A timebox is the definition of fixed resources and schedule for producing a deliverable or set of deliverables. The fixed components of a timebox include a deliverable and the associated resources, schedule and tasks needed to produce that deliverable. Figure 1.0 Conceptual View of a Timebox Timeboxing is designed to harness the reduced communications and increased focus dynamics associated with small teams and short schedules. The timebox helps the development team understand the appropriate level of resource requests by defining a deliverable and specifying the set of tasks and the fixed timeframe needed to produce the deliverable. Effective implementation and use of timeboxing supports a more rational approach to resource requests and scheduling for those tasks that can be timeboxed. Timeboxing vs. Target Dates or Deadlines Do not confuse a timebox with a target date or deadline. Timeboxing assigns specific resources to the production of a deliverable for a fixed number of work days. By contrast, a target date specifies a goal for the deliverable to which any number of resources can be applied, and deadlines often entail a flurry of activity at the end, resulting in marginal quality and organizational chaos. A timebox should be characterized by an organized and consistent work effort that meets its responsibilities; these characteristics derive from the organization and rational allocation of resources to the development effort. Aikataulu

31 The V-model Application level Component level validate against specks
Business Performance Model Prepare and Execute and Requirements Business Capability Release Test Identify Application Requirements (TP) Prepare and Execute Analyze Application Application Requirements Product Test (TP) (TP) Design Prepare and Application level Application Execute Architecture Assembly Tests (TP) (T) Verify Application validate against specks verify against higher level of detail test against right level of detail testing takes 70% of development time!!! Quality Perform Prepare and Application Execute Detailed Design Component (TP) Tests (T) Component level Generate Module (T)

32 RUP = Rational Unified Process XP = eXtreme Programming
Muita metodologioita RUP = Rational Unified Process XP = eXtreme Programming

33 Yleiskuva RUP:ista (Rational Unified Process)
RUP on järjestelmäkehitysprosessi Perustuu järjestelmäkehityksen ´parhaisiin toimintatapoihin´ (best practices) Iteratiivinen kehitys Vaatimusten hallinta Use case driven Arkkitehtuurikeskeinen, komponenttien käyttö Mallinnus UML:llä

34 RUP:n työnkulku ja projektin vaiheet
Mapping to BIM: Iception= Vorstudie Elaboration= Fachkonzept Construction= Build / Implementierung Transistion= Rollout

35 Suhteellisen pienissä projekteissa (max. 20 henkeä)
Milloin käyttää XP:tä? Suhteellisen pienissä projekteissa (max. 20 henkeä) Tilanteessa, jossa: resurssien määrä on ennalta rajoitettu sisäiset kehitysprojektit on vahva luottamus tilaajan ja toimittajan välillä release 2 onnistuneen release 1:n jälkeen ollaan jo kerran epäonnistuttu tehtiin perinteisesti, vaatimukset muuttuivat koko ajan, mitään ei tullut valmiiksi

36 Yleisiä havaintoja XP:stä
Vaatii kaikkien osapuolien koulutusta Vaatii tilaajalta paljon tarkempaa paneutumista tilattuun sovellukseen ("white box" vs. "black box") Jos enemmistö ohjelmoijista on kokeneita, XP voi olla erinomainen ympäristö kasvattaa uusia osaajia "Lähes valmis" ei riitä

37 RUP = Rational Unified Process
XP ja RUP? RUP = Rational Unified Process Olio-orientoituneista metodologioista ehkä kuuluisin Iteratiivinen prosessi dX on täysin RUP:in mukainen kehitysprosessi, joka "sattuu" olemaan identtinen XP:n kanssa

38 Projektien erilaisuuksien tunnistaminen
Sopivan johtamis- ja hallintamenettelyn määritys: esim. vesiputousmalli vai iteraatiot? Mikä on projektin tavoite? projektin tavoitteet; teknologiaa vai business hyötyä ajaako aika vai laatu 80/20 -sääntö Projektin muotoon vaikuttaa muukin kuin "e". Projektin muoto saa myös muuttua matkan aikana, jos tarpeen.

39 Projektin tyypin tunnistaminen yleisten skenaarioiden avulla
Laajan muutosohjelman implementointi Enterprise resource planning (ERP) program -käyttöönotto Räätälöidyn ratkaisun käyttöönotto, erityisiä joustavuusvaatimuksia Pakettiohjelmiston käyttöönotto, rajatusti räätälöintiä Pakettiohjelmiston käyttöönotto, huomattavaa räätälöintiä Asset based (~ olemassaolevan pohjalta) Netcentric (~ webbipohjainen) Mainframe Eräajopohjainen ratkaisu Räätälöity Paketti Komponentti Paketti -> Räätälöity Komponentti / Räätälöity

40 Projektin komponentteja vertaamalla voidaan tunnistaa projektin tyyppi
miksi projektit ovat erilaisia projektin tavoite aikataulu, resurssit uuden toiminnallisuuden (kyvykkyyden) elementit organisaatio prosessit teknologia Harjoitustyössä voidaan nähdä kolme erilaista projektia (vai voidaanko?)

41 Liiketoiminta-arkkitehtuuri
Tulos Osaaminen Kulttuuri Sovellukset Laitteet Organisaatio Toteutus- ja tuotanto- ympäristöt Tilat Prosessit Strategia Visio/missio Tuotteet, palvelut, hinnoittelu Asiakas-vaatimukset Jakelukanavat Markkina-asema Kohdeasiakkaat/markkinat Tarvittavat valmiudet Toimintarakenteet Hankintapolitiikka Toiminnan suuntaviivat Strateginen Taloudellinen Operationaalinen Osakkeenomistajat Henkinen Käyttäytyminen Arvot Normit Motivaatio Toiminnot Tehtävät Työnkulku Toimintaohjeet Odotukset Informaatio Osajärjestelmät Komponentit Modulit/luokat Data Palvelimet Työasemat Koneet/oheislaitt Työkalut Tekniset arkkitehtuurit Käyttöpalvelut Operointipalvelut Verkot Rakenteet Tiimit, roolit Toimenkuvat Taidot Tietämys Taipumukset Sijainti Rakennukset Omaisuus Oheispalvelut

42 Erilaiset projektit vaativat erilaisia hallintatapoja
Rajoittava tekijä on joskus aika resurssit laajuus ...tai jokin muu

43 Muuta projektien tyypistä
Miten projekti on asetettu? projekti linjaorganisaatiossa vai erillisenä projektina, jolla on omat (100%) nimetyt resurssit valtava merkitys projektin mahdollisuuksiin onnistua Missä projekti tapahtuu fyysisesti? hajauttaminen lisää kompleksisuutta Miten projekti on vaiheistettu? rahaa saadaan vasta kun koko työ on tehty

44 Harjoitustyö esittelee hankkeen, jossa voidaan nähdä kolme projektia
Case - arkkitehtuuri Harjoitustyö esittelee hankkeen, jossa voidaan nähdä kolme projektia Toteutettava osio Jällenmyyjät Internet WWW Palvelin B2B Logiikka Adapteri AS/400 Mahdollistaa Tilaukset Jällenmyyjät Turun Kirjapaino Laskut

45 Kolme esimerkkiä erilaisista lähestymistavoista
Osaprojekti WWW-projekti B-to-B logiikka Adapteri Menetelmä, lähestymistapa Komponenttikehitys, iteraatiot, timeboxing Räätälöity, paketin käyttöönotto, timeboxing(?) Räätälöity, paketin käyttöönotto(?) Tavoite: tunnistaa eri tyyppisen projektin ja toteutustavan yhteys. Nähdä ettei ole olemassa yhtä oikeata ratkaisua. Tuniistaa projektin hallinnan erilaisuuksia erilaisissa projekteissa: timeboxing speksit selvät heti alussa (interface), selkeä aikataulu ja ”kuri” spekesit muotoutuvat protoilun myötä (www), vapauksia, tiukka kommunikointi, jatkuva projektin myyminen jne... Jaetaan ryhmä 2-3 hlön ryhmiin. Kukin miettii millaisella projektilla lähtisi tekemään yhtä CASEn projekteista. Projektin tyypit annettu Projektin tyypin luokittelu annettu Projektin hallintatapa annettu

46 Päätöksentekokriteerejä
Tehtäisiinkö itse? Ei ydinosaamista? Tärkeä oma osuus? Kuka muu osaa? Missä tulee käyttöön? Globaali? Voidaanko hallita keskitetysti? Missä rajapinnat (loogisesti/fyysisesti)? Tavoite: tunnistaa eri tyyppisen projektin ja toteutustavan yhteys. Nähdä ettei ole olemassa yhtä oikeata ratkaisua. Tuniistaa projektin hallinnan erilaisuuksia erilaisissa projekteissa: timeboxing speksit selvät heti alussa (interface), selkeä aikataulu ja ”kuri” spekesit muotoutuvat protoilun myötä (www), vapauksia, tiukka kommunikointi, jatkuva projektin myyminen jne... Jaetaan ryhmä 2-3 hlön ryhmiin. Kukin miettii millaisella projektilla lähtisi tekemään yhtä CASEn projekteista. Projektin tyypit annettu Projektin tyypin luokittelu annettu Projektin hallintatapa annettu


Lataa ppt "Tik Ohjelmistoprojektien Hallinta"

Samankaltaiset esitykset


Iklan oleh Google