és azzal mi a baj?

agilis nem azt jelenti hogy "csapd össze"



ezeket a frameworköket/toolokat akarod felhasználni, testreszabni a saját igényeknek megfelelően, iterációnként újragondolni/finomítani, ... - nem feltétlenül csak egyet felhasználva, ezer use case van arra, hogy a scrum nem működik 1:1-ben nagyon sok helyen és kanbanosítják, stb.

a technical dolgoknak ehhez nagyon semmi köze

"Agile methods are sometimes called lightweight methods, specifically because they are less prescriptive than traditional methods."

This post was edited by Anarkin on Jun 25 2015 03:12pm

Az, hogy elvileg nem lenne szabad olyan rendszert ezekkel fejleszteni, amin emberek élete múlhat.
Nem tudok belemenni hosszas fejtegetésekbe, mert az agilis szoftverfejlesztésről valószínűleg a kisujjadban több van, mint nekem.
Viszont az autóiparban az agilis módszereket elvileg nem szabad használni a biztonságkritikus részeken. Ez a szabályzatban le van fektetve.

Bár nem mintha bármilyen szabályt is betartanánk.
Biztonságkritikus rendszerben 90% feletti memóriahasználatunk van. Még leglazább esetben sem lehetne 70% felett (ez előírás), de nem ritka, hogy az 50%-ot célozzák meg (vevő eredeti elvárása).

Nem véletlenül akarok lépni innen.

ezek nem saját gondolatok amúgy szóval érveléses vitába nem tudok belemenni, csak annyit tudok elmondani, hogy szabályellenes.

Agile analysis practices for safety-critical software development
Because of their discipline and efficiency, agile development practices should be applied to the development of safety-critical software. Bruce Douglass, author of the IBM Rational Harmony for Embedded RealTime Development process, explains the key analysis practices for the development of safety-critical systems and how they can be realized in an agile way.

Agile methods have a reputation for being fast and adaptive but undisciplined and lacking in robustness. However, agile methods require a great deal of discipline, and these practices enhance both quality and team productivity. Because of this, agile development practices should be applied to the development of safety-critical systems. This article describes how agile analysis methods can be used in the development of safety-critical systems.

Properties of safety-critical systems
The term safety-critical refers to systems that either can cause harm or are responsible for preventing harm. Such systems range from medical devices to automotive braking systems, nuclear power plant control to avionic flight management systems. Most safety-critical systems must be certified by a regulatory agency to ensure that they are fit-for-purpose. This means that proper development practices have been applied toward "system correctness" as the outcome and that adherence to the objectives of the relevant standards can be demonstrated.
Because it is virtually impossible to demonstrate deterministic correctness for any significant piece of software, most of these standards have concentrated on specifying process objectives and requirements for evidence that the process standards have been followed. For example, the recently released avionics standard, DO-178C, Software Considerations in Airborne Systems and Equipment Certification, requires that a system project supply evidence in several categories for up to 71 objectives, depending on the safety-criticality level. Supplements for this standard, such as DO-331, Model-Based Development and Verification, and DO-332, Object-Oriented Technology and Related Techniques, add objectives if those technologies are employed.

Most such objectives relate to the following phases:
Planning (including the specification of the safety level of the device)
Software development process definition
Requirements management
Software design and coding
Configuration management
Quality assurance
Integration
Verification
Tool qualification
System certification

It is important to note that while these standards specify the objectives that any process must meet if it is used to develop a safety-critical system, the standards do not specify the processes themselves. As long as a process can be demonstrated to meet the needs of the relevant standard, the development team is free to use whatever processes they want to use. This leaves the option available to use state-of-the-art agile methods, with all of their accompanying advantages, provided that the safety objectives can be achieved.

[...]

This post was edited by Anarkin on Jun 25 2015 03:26pm

tobbnyire en is automotiv dolgokkal dolgozok(bar en tavolrol se programozok) es eleg nehez elhinni hogy ilyen feltetelek mellett barki uzletelne veletek amikor minden hibarol 8Dt kell futtatni az OEMig es az elso ilyen eset lattan visszadobnanak toletek mindent mikozben sirva verik az asztalt

Anarkin idezetebe csak beleolvastam de az automotive standardek tulnyomo tobbsege szigorubb a (polgari) repulesi sztenderdeknel mert az automotiv rendszerekben nincs haromszoros redundancia

Most ezt úgy mondod, mintha nem lett volna már olyan botrány, ahol többek között pont ezek kiderültek egyik-másik márkánál.
Ezek 20 centért az anyjukat is megbasszák.

Lehet voltak mar botranyok de nem az az altalanos - es elkepeszto penzeket elkoltenek arra acegek hogy meggyozzek egymast a megbizhatosagukrol, a modellenkenti ciklusok vegett mashogy nem is lehet.

Lehet R&D szinten meg igy latszodik, arra nincs ralatasom - de elesben nagyon nem igy mukodik.

Én nem általánosságban beszéltem, hanem a projektről ahol vagyok és ahonnét menekülni akarok.

Ahol előzőleg voltam cégen belül, ott nem voltak ilyen gondok. Ott (szinte) minden az előírás szerint ment.

This post was edited by CyberPunk666 on Jun 26 2015 09:03am

Menj át a bankszektorba, ott mindenhol minden előírás szerint zajlik de felkötöd magad annyi az adminisztráció.

felettunk ilyen befektetesi bank a kliens
remote desktopon dolgoznak es ki kell menniuk internetezni egy kulon szobaba
#eletke